1. Field of the Invention
The present invention relates to a packet data service during a handover or handoff of a user terminal in a mobile communication system, and particularly, to a method of performing Serving Radio Network Subsystem (SRNS) relocation and a structure and an operation method of a packet data convergence protocol layer (PDCP) which is able to support the SRNS relocation in a packet service area.
2. Description of the Related Art
Recently, a Third Generation Partnership Project (hereinafter, referred to as 3GPP) was formed by national or international or regional standardization organizations, such as ETSI of Europe, ARIB/TTC of Japan, T1 of USA, CWTS of China, and TTA of Korea in order to make a detailed specification of a European type third generation mobile communication system (IMT-2000 system). This system is called as UMTS (Universal Mobile Telecommunications System). UMTS adopted WCDMA (Wideband Code Divisional Multiple Access) technology as a radio access network technology. UMTS is being developed based on the General Packet Radio Service (GPRS) making its root on a packet-switched network and further based on the Global System for Mobile Communications (GSM) making its root on a circuit-switched network. In addition, the third generation mobile communication systems which are able to provide multimedia services, such as voice, video, and data, are under development in the above partnership.
The 3GPP includes five technical specification groups (TSG) in order to administer the project and to rapidly and effectively develop the technology. Each respective TSG takes charge of development, approval, and management for a reference specification of related area. Among those groups, a radio access network (RAN) group develops functional requirements of a terminal and UMTS Terrestrial Radio Access Network (UTRAN), and develops specifications for an interface under an object of defining a new radio access network in the third generation mobile communication system. And a core network (CN) group develops specifications for function, requirement, and interface of the CN in order to connect the UTRAN to a circuit-switched backbone network or to a packet-switched backbone network.
FIG. 1 shows a network structure of a packet-switched domain suggested by the TSG-RAN and TSG-CN.
As referring to FIG. 1, the UTRAN comprises a plurality of radio network subsystems (RNS). Each RNS comprises a plurality of Node Bs and one radio network controller (RNC).
In addition, the CN has different structure according to the adopted switching mode (packet-switched network or circuit-switched network). In case of the packet-switched network considered in the present invention, the CN comprises a plurality of serving GPRS support nodes (SGSN) and one gateway GPRS support node (GGSN).
Functions of respective components shown in FIG. 1 will be described as follows. The Node B functions as a connecting point where a User Equipment (UE), (commonly called as a mobile station or a terminal), connects to the UTRAN, and RNC assigns and manages radio resources to respective UEs.
The RNC can be classified into a control RNC (CRNC) for managing shared radio resources, and a serving RNC (SRNC) for managing dedicated radio resources allocated to the respective terminals.
In the view point of a certain UE (terminal), the RNS where the SRNC of the above UE is located is called as serving RNS (SRNS). The SGSN routes information transmitted from the UTRAN to CN, and GGSN functions as a gateway, which passes the information from the UTRAN to other CNs in case that an information destination is not the present CN, but another network. A packet domain network (PDN) is a back bone network of the packet-switched domain for supporting the connection between the other networks in the packet service domain.
Data interfaces on the respective parts have different names as follows. For example, an interface between the UE and the Node B is “Uu” interface, between Node B and the RNC is “lub” interface, between the RNC and the RNC is “lur” interface, between the RNC and the SGSN is “lu” interface, and between the SGSN and the GGSN or the SGSN and the SGSN is “Gn” interface.
FIG. 1 is an exemplary example of network structures. The lur interface may not exist as a real interface, and the lur interface may exist between the RNCs of different SGSN. Also, the Gn between the SGSNs may exist or may not exist.
The network structure shown in FIG. 1 can be presented as a layered structure as shown in FIGS. 2 and 3. FIG. 2 is a view showing a user plane (U-plane) layer structure for transmitting user data. FIG. 3 is a view showing a control plane (C-plane) layer structure for transmitting a controlling signal.
FIG. 4 is a view showing detailed layers of a UE side or a UTRAN side supporting the Uu interface, which is a radio interface (an air interface), shown in FIGS. 2 and 3.
As shown therein, the U-plane comprises a packet data convergence protocol layer (PDCP), a radio link control layer (RLC), a medium access control layer (MAC), (these three layers work as a Layer 2 in the Open Systems Interconnection scheme) and a physical layer (L1 or Layer 1) as a Layer 1 of the Open Systems Interconnection scheme. In addition, the C-plane comprises: a radio resource control layer (RRC), an RLC layer, an MAC layer, and an L1 layer.
The L1 layer (physical layer) provides the upper layers with an information transfer service using various radio accessing technologies. The L1 layer is connected to the MAC layer via a transport channel, and the data between the MAC layer and the L1 layer are exchanged through the transport channel. The transport channel is divided into a dedicated transport channel if the channel is used by a terminal exclusively and a common transport channel if the channel is shared by a plurality of terminals.
The MAC layer provides a MAC parameter relocation service for locating and relocating the radio resource. The MAC layer is connected to the RLC layer through a logical channel, and different kinds of logical channels are provided according to the kinds of information which are transmitted. Generally, a control channel is used when the information on the C-plane is transmitted, and a traffic channel is used in case that the information on the U-plane is transmitted.
The RLC layer provides services of establishing or releasing the radio link. Also, the RLC layer performs the segmentation and reassembly functions of RLC service data unit (SDU) descended from an upper layer on the U-plane. The size of the RLC SDU is controlled on the RLC layer, and the header information is added to the RLC SDU to make a protocol data unit (PDU) form, and then, the PDU is transmitted (delivered) to the MAC layer.
The PDCP layer is an upper layer of the RLC layer and changes the data which is transmitted through the IP network protocol, such as IPv4 or IPv6, into a form which is suitable for the RLC layer to transmit the data. Besides, the PDCP layer reduces controlling information which is used in a wired network, but unnecessarily large to the radio network to transmit the data effectively through the radio interface. The above function is called as a header compression, and can be used to reduce the header information used in TCP/IP.
The RRC layer provides an information broadcast service for broadcasting system information to all terminals located on an optional area. Also, the RRC layer processes C-plane signals for control signal exchanged in a Layer 3, and performs establishing, re-configuring, and releasing radio resource between a terminal and the UTRAN. Particularly, the RRC has the functions of establishing, re-configuring, and releasing a radio bearer (RB), and functions of allocating, relocating, and releasing the radio resources needed in radio resource connection. The RB means a service provided by a Layer 2 for transmitting data between the terminal and the UTRAN. In other words, establishing a RB means a process in which a protocol layer and channel characteristic for providing a predetermined service in a radio area are determined, and parameters and operational method are set respectively.
The lu interface can be characterized in different types according to the functions. The lu-CS (lu circuit service) is used in the circuit-switched service, and lu-PS (lu packet service) is used in the packet-switched service.
The lu-PS will be described because the present invention makes reference to the packet switched domain. The lu-PS supports the packet data transmission. The GPRS tunneling protocol for the user plane (GTP-U) layer is used on the U-plane, and is used especially for transmitting user data in the packet switched area. In addition, the packet switched network in the UMTS is based on the GPRS, and therefore, the GTP-U is also used in the UMTS.
A radio access network application part (RANAP) layer is used in the C-plane of the lu interface, and transmits the control information. The RANAP layer is used in both the lu-CS and lu-PS.
FIG. 5 illustrates a SRNS relocation procedure. The SRNS relocation means a process of changing SRNC from a source RNC to a target RNC in order to set an lu connection point between the UE and the CN with a shorter path, in case that a handover is generated between RNS by the UE.
In FIG. 5, the old SGSN connected with the source RNC is different from the new SGSN connected with the target RNC. However, the old SGSN and the new SGSN may be the same. That is, the SRNC may be changed without the SGSN being changed.
The SRNS relocating procedure not permitting a data loss is called as lossless SRNS relocation (LSR). The LSR is important in transmitting the packet data. The reason is that a data loss in the packet data means the loss of the entire data since such packet data is not useable although some losses in real time data, such as voice data, are permissible and cause little adverse affect.
Therefore, the 3GPP has been making efforts to come up with the complete LSR procedure, however, it leaves much to be desired.
Hereinafter, the typical packet data transmitting/receiving process of a wireless communication systems supported by the 3GPP standard or other standards will be described, by using as an example of downloading the packet data in the UE.
FIG. 2 is the reference view and FIG. 6 is a view showing the packet data flowing on the U-plane.
First, the GGSN requests the SGSN to which the UE is connected to set a radio access bearer (RAB) in order to transmit the data which is required by the UE. The SGSN which received the above request assigns the RAB to set the transmission path of the data between the UE and itself.
When the transmission path from the GGSN to the UE is set, the GGSN starts the packet data transmission. The packet data generated in upper layers (IP, PPP etc.) are encapsulated as GTP-U PDU (Protocol Data Unit) in the GTP-U layer of the GGSN and transmitted to the RNC of the UTRAN. The GTP-U layer of the UTRAN RNC receives the above GTP-U PDU, and decapsulates the GTP-U PDU to extract the packet data. Generally, the GTP-U layer transmits the GTP-U PDU after adding GTP-U sequence numbers on the GTP header for in-sequence delivery and for reliable delivery.
Thereafter, the GTP header is removed from the GTP-PDU, and the remaining packet data is transmitted to the PDCP layer of the UTRAN. In addition, the PDCP layer performs header compression for the packet data (PDCP SDU in FIG. 6). Herein, the header compression means downsizing of an IP header on the packet of the normal IP protocol. The header compression is performed for the respective packets (PDCP SDU). The PDCP SDU subjected to the header compression becomes PDCP PDU.
The PDCP PDU is transmitted to the UE by passing through the RLC, MAC, and L1. The transmitted PDCP PDU is delivered to the PDCP of the UE by passing through the L1, MAC, and RLC in the UE. Then, a header decompression is made using reverse algorithm to that of the header compression. Then, the extracted PDCP SDU is transferred to the upper layer (PPP, IP). IP packets from UE side can be transmitted to the UTRAN side by similar manner.
FIG. 7 is a view showing a PDCP structure which controls the transmitting/receiving of packet data in radio interface (air interface) among the layers related to the packet data flowing.
As shown therein, one PDCP entity exists per respective radio bearer (RB), and one PDCP entity is connected to one RLC entity.
The PDCP entity may be connected to three types of RLC entity, that is, AM (Acknowledged mode, a mode for confirming by receiving side whether or not the data is transmitted), UM (unacknowledged mode, a mode in which the data transmission is not confirmed by the receiving side), and TM (transparent mode, a mode for passing the data transparently). However, in case that the LSR is used, the PDCP entity is only connected to the RLC AM entity in order to ensure the in-sequence delivery of the PDCP PDU.
The operation of PDCP is varied according to which mode among those three kinds of mode is used in the RLC entity to which the PDCP is connected. Herein, a case that the PDCP is connected to the RLC AM entity which supports the LSR will be described.
When the PDCP SDU is delivered from the GTP-U, the PDCP performs the header compression using a compression algorithm. The header compression is performed for the IP (internet protocol) header in the PDCP SDU, and two algorithms of RFC2507 and RFC3095 used for the header compression are defined presently.
The algorithm which will be used in the header compression is informed by the RRC when the PDCP entity is established. In addition, various compression algorithms may be used, or the compression may not be made (i.e., by passed).
When the PDCP SDU has passed through the header compression process, the PDCP SDU becomes the PDCP PDU. After that, if the PDCP supports the LSR, the respective PDCP PDU is being numbered, and the sequence numbers are managed by the PDCP. The sequence number of the PDCP PDU of sender is increased by 1 whenever one PDCP PDU is descended to the RLC, and the sequence number of PDCP PDU of the receiver is increased by 1 whenever one PDCP PDU is delivered from the RLC or the discard information indicating that one PDCP PDU (=RLC SDU) is discarded is delivered from the RLC. The PDCP manages the sequence number (SN) in order to prevent a loss of PDCP SDU when the SRNS relocation is occurred.
FIG. 8 is a view showing the types of PDCP PDU. There are three types of PDU generated by the PDCP. A PDCP-No-Header PDU uses the PDCP SDU as the PDCP PDU directly without overhead information. The above PDU is used in case that the header compression is already made at the upper layer, and the PDCP transfers the PDCP SDU to the RLC transparently.
Second, a PDCP data PDU is mainly used in the PDCP, and notifies the header compression type, which is used for the corresponding PDCP PDU, through a PID field.
The PDU type field notifies whether the corresponding PDU is the PDCP data PDU or the PDU is a PDCP SeqNum PDU which will be described later.
Third, the PDCP SeqNum PDU is used when the PDCP data PDU is transmitted with a sequence number.
The PDCP SeqNum PDU is sent for coincidence of RSN (Receive Sequence Number) of receiver and SSN (Send Sequence Number) of sender in case that the SN of a PDCP PDU of the sender PDCP entity and of the receiver PDCP entity are not synchronized with each other. The RSN preferably corresponds to the next expected sequence number, and the SSN corresponds to the first unsent sequence number.
The above process of coinciding the SNs of the PDCP entities by transmitting the SeqNum PDU is called as an SN synchronization process.
If the SRNS relocation is occurred when the packet data is transmitted/received, the PDCP performs different operations according to the modes.
There are two modes in the SRNS relocation, one is a lossy SRNS relocation, and the other is a lossless SRNS relocation.
The lossy SRNS relocation is a method for performing handover as permitting a loss of packet, and is applied to a real time traffic, such as a voice over IP (VoIP) and a streaming service. According to the above method, the PDCP does not receive any acknowledgement (hereinafter, referred to as ACK) for the PDCP PDU transmitted by itself from the RLC, and does not perform a special operation during the SRNS relocation. That is, the PDCP performs the header compression for the PDCP SDU transmitted from the GTP-U and descends to the RLC.
On the contrary, in case of the lossless SRNS relocation (LSR), even a loss of a packet is not permitted, and therefore, the PDCP performs more complex operations than the lossy SRNS relocation. The LSR is mainly applied to a service which does not require the real time traffic (e-mail, FTP, and web browsing, etc.), because most of the data permitting the non-real time traffic have a characteristic that if a part of the data is lost, then entire data is lost. Therefore, in the case that the LSR is used, the SN is used in the PDCP in order to manage the PDCP PDU transmission/receive. In addition, if the SNs of the sender PDCP and of the receiver PDCP are different from each other, a special PDU for notifying the SN, that is, the PDCP SeqNum PDU is used for synchronizing the SNs of both sides. In addition, the RLC uses only the AM among the TM, UM, and AM, and also uses in-sequence delivery method.
The PDCP SN is in the sender and in the receiver, respectively. The send SN is used in the sender, and the receive SN is used in the receiver.
The send SN is increased by 1 whenever one PDCP PDU (same as the RLC SDU) is descended to the RLC from the PDCP, and the receive SN is increased by 1 when a normal PDCP PDU (=RLC SDU) is transmitted from the RLC to the PDCP, or when a signal representing a RLC SDU is discarded is transmitted from the RLC to the PDCP. In addition, when one PDCP SeqNum PDU is transmitted, the send SN is updated as the value notified by the above PDU.
FIG. 9a and FIG. 9b are views showing the process of LSR in case that the UE performs a handover between the RNS suggested in the conventional 3GPP specification. FIG. 9a shows downlink protocol and FIG. 9b shows uplink protocol.
Hereinafter, FIG. 9a will be described using the reference numerals shown in the FIG.
First, step 1 shown in FIG. 9a represents a process of requesting relocation to the PDCP by the source RRC after suspending operations under the PDCP layer when the UE requests the handover to another RNS and the SRNS relocation is needed.
The PDCP which received the relocation request in step 1 notifies the source RRC of a DL (down link) SSN of the PDCP PDU which will be transmitted to the down link (hereinafter, referred to as DL) at next first time, and a UL (uplink) RSN of the PDCP PDU which will be transmitted from the uplink (UL) at next first time. Although the SRNS relocation is occurs concurrently in the downlink and uplink, each link will be separately described for easier understanding.
For example of a downlink, if the sender source PDCP delivered PDU 20 to the RLC, the next DL SSN will be numbered 21 (step 2). The source RRC receives the DL SSN from the PDCP in step 2 and transmits it to the target RRC (step 3).
In step 4, the source PDCP transmits the PDCP SDUs, which are not confirmed by the UE through the RLC among the PDCP SDU transmitted to the UE, to the target PDCP through the GTP-U (the layer supporting the packet data transmission on the U-plane, not shown). If the PDUs are transmitted up to PDU 20 to the UE and the transmission success of the PDUs are confirmed up to PDU 15 at the UE, the SDUs corresponding to the unconfirmed PDU 16˜PDU 20 are transmitted to the target PDCP (step 4).
The UE PDCP notifies the UE RRC of the DL RSN of the first PDCP SDU which will be transmitted from the UTRAN to the UE at next time (step 9). An SN of a PDCP SDU has the same meaning as that of PDCP PDU.
In step 10, the UE RRC notifies the RRC in the target RNC of the DL RSN. The target RRC compares the DL RSN transmitted from the UE to the DL SSN transmitted from the source RRC to decide the first DL PDCP SN of the PDCP SDU which will be transmitted to the UE at next time.
If the DL RSN is larger than the DL SSN, the DL RSN is regarded as invalid (since received sequence number cannot be larger than the send sequence number), and the target RRC commands to start the SN synchronization process to the PDCP. DL RSN≦DL SSN is a normal case, and then, the First DL PDCP SN will be DL RSN (step 11).
The target RRC notifies the target PDCP of the First DL PDCP SN (DL RSN) which will be transmitted to the DL first. After that, when the transmission is restarted, the target PDCP transmits the SDU corresponding to the First DL PDCP SN (DL RSN) to the DL (step 12).
Referring to FIG. 9b, for example of uplink, if the receiver source PDCP received PDU with sequence number 50 from the RLC, next UL RSN will be numbered 51 (step 2).
The source RRC receives the UL RSN from the PDCP in step 2 and transmits it to the target RRC (step 3). The target RRC or the source RRC notifies the UE RRC of the UL RSN.
The UE RRC notifies the UE PDCP of the UL RSN received from the target RRC or the source RRC, after suspending the operation of the RLC. The UE PDCP then transmits the SDU corresponding to the UL RSN to the UL when the transmission is restarted next time (step 8).
However, according to the conventional PDCP protocol specification for performing the lossless SRNS relocation, it is not defined how to manage a PDCP buffer which is needed to transmit the unconfirmed PDCP SDU when the lossless SRNS relocation process is performed. Also, not defined is how to process a gap generated on the PDCP SN after the LSR by the header compression context state.
Also, not defined is how to do if the SNs between the PDCPs are different from each other, how to decide the PDCP SDU data transmission point, and how to operate the PDCP receiver after the LSR process.
Moreover, a problem of modular comparison which is generated when the target RRC compares the SN can not be solved yet.
Therefore, if the PDCP is operated according to the conventional art suggested in the PDCP protocol specification for supporting the LSR, the SRNS cannot be relocated without a loss. Accordingly, the lossless transmission/reception of the packet data in a mobile environment can not be made.